Subject: finishing this MIB !

From: "Peter W. Gayek" <[email-masked]>
Date: Mon, 19 Feb 96 15:26:41 EST

Fellow DLSw MIBers,
As far as I know there are only 3 open issues standing in the way of
asking for an RFC number on this thing.
  1) the timestamp issue raised by Jim Cobban in early November,
     relating to all the SNA-related MIBs
  2) Jim's request on 12/13/95 that InstancePointer objects be
     redefined either as VariablePointer or RowPointer objects.
  3) any comments that come out of the IETF directorate review of
     the MIB, which is way overdue

I know Shannon is trying to get some response on #3, so I guess we all
have to keep waiting on that one (Shannon, would it help if multiple
people/companies asked about the status?).  But it seems to me that
we can resolve issues 1 and 2 now so I thought I would take a stab at
them.  I proposed some resolutions below that could be implemented in
our final draft along with any comments from #3.  Please post any
comments you may have.

Issue 1 - timestamps
====================
After considerable discussion on several mailing lists throughout
November, all the SNA-related MIBs seem to have reached consensus
on how to resolve this problem.  It was basically to change timestamp
objects to be durations in timeticks.  If we apply this same solution
to the DLSw MIB, the following changes would result:

  - DlswTimeStamp textual convention is removed

  The following objects have modified definitions as follows:
  - dlswTConnConfigLastModifyTime
      duration since last change to row
  - dlswTConnOperEntryTime
      duration since the oper row was created
  - dlswTConnOperConnectTime
      duration since the TC went "connected"
  - dlswTConnOperDiscTime
      duration since the TC last went "disconnected"
  - dlswCircuitEntryTime
      duration since the circuit table row was created
  - dlswCircuitStateTime
      duration since the circuit last changed state

Note that dlswNodeUpTime stays as it was, because it was already a
duration.

Issue 2 - InstancePointer
=========================
Jim listed the following 6 objects that are currently defined as
InstancePointer, which is now an obsolete textual convention:
  dlswTConnConfigGroupDefinition
  dlswDirMacLocation
  dlswDirNBLocation
  dlswDirLocateMacLocation
  dlswDirLocateNBLocation
  dlswCircuitS1Dlc

Dave and I propose that all 6 of these objects be changed to type
RowPointer.  The last 3 are defined as pointing only to rows.  The
first 3 will almost always point to rows, but the descriptions do allow
for pointing to something that is "implementation defined".  It seems
to me that even these objects will be rows.  If anyone feels otherwise,
please speak up and we can create our own textual convention that is
roughly equivalent to the old "InstancePointer".

Dave also mentioned to me that there should be a few editorial changes
in the final draft of the MIB to update references to the latest SNMPv2
documents.

Does anyone have objections to or comments about these proposals?  Have any
other issues been raised in the past that I missed?

Peter Gayek
IBM Corp.

---

From: Shannon Nix <[email-masked]>
Date: Fri, 1 Mar 96 14:37:22 EST

Hi,

Peter posted the following list of open issues two weeks ago.

With respect to item #3, I have contacted the IETF NM directorate and
Kaj (Tesink) has pledged to redouble his efforts to complete the review.

With respect to #1 and #2,  the proposed resolutions put forth by
Peter seem like workable solutions.  I have heard no feedback from
this group concerning these proposals.  It think it is likely that
the IETF would find these proposals acceptable.

SO....if any of y'all object to the attached proposals to resolve the
first two issues, speak up.  If I don't hear something SOON, I will
recommend that Dave and Peter implement the changes in an interim 
draft pending feedback from IETF.

That brings me to issue #3.  I will try to stay on top of this so that
we can get the review and post the next draft.  IETF is meeting
in LA this week, so I'm sure I won't get any resonse from Kaj this
week.  However, I'll recheck our status next week. 

In fact, if the following assertions hold:

1)  There are no objections on items #1 and #2.
2)  Kaj has not started the review of our previous draft.

Then we should try to post a new draft to CNRI and point
Kaj to that one.

Unless someone raises a significant issue, I was not planning to
request any time at this upcoming AIW.  At this point, I don't plan
to attend and I know Peter is unable to as well.  Does anyone
NOT feel that we can tie up these loose ends on this mail list?

Comments?

Shannon